feat(core): support render-only visibility on dock entries#470
Merged
Conversation
Bump devframe/@devframes/hub to ^0.7.13, which adds a render-only `visibility` field alongside `when` on dock entry declarations (devframes/devframe#136). `visibility` hides only an entry's own dock-bar button while leaving it fully registered and reachable (activation, RPC, the subTabs frame-nav adapter). Wire it into the client-side dock rendering: docksGroupByCategories (the choke point behind the dock bar, group popovers, edge sidebar, and command-palette group children) and DockEntries' per-button gate now skip entries whose `visibility` evaluates falsy, mirroring the existing `when` handling. The settings management view continues to list every entry via `includeHidden`, so visibility-hidden entries stay discoverable there. Documents the new field and its canonical subTabs-anchor use case in docs/kit/when-clauses.md and docs/kit/dock-system.md. Created with the help of an AI agent.
@vitejs/devtools
@vitejs/devtools-kit
@vitejs/devtools-oxc
@vitejs/devtools-rolldown
@vitejs/devtools-vite
@vitejs/devtools-vitest
commit: |
antfubot
added a commit
to nuxt/devtools
that referenced
this pull request
Jul 24, 2026
Bump `@devframes/hub` to 0.7.13 and adopt its new render-only `visibility` field (devframe#136): set `visibility: 'false'` on the shared-frame anchor so only its synthesized per-tab members render, while the entry stays registered and keeps hosting the shared iframe / driving the frame-nav loop. This replaces the host-side client-dock override hack that dynamically set `when: 'false'` after members bootstrapped. The dock-bar button is suppressed by the viewer once it honors `visibility` (vitejs/devtools#470, @vitejs/devtools 0.4.7); the field is inert on older viewers.
antfubot
added a commit
to nuxt/devtools
that referenced
this pull request
Jul 24, 2026
Bump `@vitejs/devtools` and `@vitejs/devtools-kit` to 0.4.7, whose viewer honors the render-only `visibility` field (vitejs/devtools#470). Together with `@devframes/hub` 0.7.13, the anchor's `visibility: 'false'` now actually suppresses its dock-bar button while the entry keeps driving the shared frame.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Bumps
devframe/@devframes/hubto^0.7.13, which lands devframes/devframe#136: a render-onlyvisibilityfield alongsidewhenon the dock entry base declaration.visibilityhides only an entry's own dock-bar button; the entry stays fully registered and reachable (docks.activate()/switchEntry()by id, RPC lookups, thesubTabsframe-nav adapter, etc.) — hub deliberately does no filtering of its own, so each viewer implements the actual hiding.This PR wires that up on the client side:
docksGroupByCategories(the single choke point behind the top-level dock bar, group popovers/sidebars, and command-palette group children) now skips entries whosevisibilityevaluates falsy, mirroring the existingwhenhandling exactly — including theincludeHiddenescape hatch so the Settings management view keeps listing them.DockEntries's per-buttonisDockVisiblegate gets the samevisibilitycheck.DevToolsDockEntry,DevToolsViewIframe,DevToolsViewJsonRender,DevToolsViewLauncher, ...) either re-exports or extends the hub'sDevframeDockEntryBase, so it inheritsvisibility?: stringautomatically from the version bump.docs/kit/when-clauses.mdand cross-references fromdocs/kit/dock-system.md, using the canonicalsubTabsshared-frame-anchor use case as the example.dock-groups.test.tscovering: dropped from the rendered dock bar, still present in the rawentriesarray, still listed viaincludeHidden, and evaluated against awhenContextthe same waywhenis.Linked Issues
Implements the UI side of devframes/devframe#136.
Additional context
test/exports.test.ts's@vitejs/devtools > runtime: .snapshot fails on this branch, but it also fails identically on an unmodifiedmainafter a freshpnpm install— confirmed by reproducing it in a scratch worktree offorigin/main— so it's a pre-existing environment/tooling issue unrelated to this change, not something introduced here.This PR was created with the help of an AI agent.